很多没有在大厂或规范团队待过的同学,项目里确实见不到 CI/CD(可能都是本地 npm run build 然后用 FTP 传服务器)。但面试时,这绝对是一个极佳的加分项。
我们可以把 CI/CD 拆成两部分:CI(持续集成) 和 CD(持续部署)。为了让你快速通关面试,我们用最通俗的语言和实际场景来拆解。
你可以把 CI/CD 想象成一个自动化的工厂流水线:
git push 把代码推送到远程仓库,剩下的检查、测试、打包、上传服务器全部由“机器人(流水线)”自动帮你完成。核心目的: 确保新提交的代码是高质量的,没有把原有的代码改坏。
机器人帮你干的事:
eslint)。build 出来。经典面试对答:
问: 你们项目是怎么做代码质量控制的?
答: 我们配置了 CI 流水线。当开发者提交 MR(Merge Request)到
main分支时,会触发 CI 流程。流水线会自动运行 Eslint 检查和单元测试,只有全部通过,代码才允许被合并。
核心目的: 把 CI 检查通过的代码,自动发布到服务器上让用户看到。
机器人帮你干的事:
dist 文件夹,或者后端的 Docker 镜像准备好。经典面试对答:
问: 你们是怎么发布上线新版本的?
答: 我们实现了 CD 自动化部署。只要代码成功合并到
release分支,CD 流水线就会启动,自动执行生产环境打包,并将静态文件推送到 Nginx 服务器/阿里云 OSS,整个过程不需要人工干预,实现了秒级发布。
在实际开发中,我们不需要自己写机器人,常用的工具有 GitHub Actions、GitLab CI/CD 和 Jenkins。现在的趋势是,中小企业极度青睐直接集成在代码仓库里的工具(如 GitHub/GitLab)。
它们的核心原理非常简单:在项目根目录下放一个配置文件(通常是 .yml 或 .yaml 格式)。
你在项目根目录创建 .github/workflows/deploy.yml:
name自动构建与部署流水线# 1. 触发时机:当代码被 push 到 main 分支时触发on push branchesmain# 2. 具体要做的工作jobs build-and-deploy runs-onubuntu-latest # 在一个干净的 Linux 虚拟机里运行 steps # 第一步:把仓库里的代码复制到虚拟机里name拉取代码 usesactions/checkout@v4 # 第二步:安装 Node.js 环境name安装 Node.js usesactions/setup-node@v4 with node-version20 # 第三步:执行 CI(安装依赖并检查、打包)name安装依赖并构建打包 (CI) run npm install npm run lint npm run build # 生成 dist 文件夹 # 第四步:执行 CD(把 dist 自动传到你的服务器)name部署到服务器 (CD) useseasingthemes/ssh-deploy@main env SSH_PRIVATE_KEY$ secrets.SERVER_KEY # 密码存在安全中心 ARGS"-rlgoDzc --delete" REMOTE_HOST"192.168.1.1" # 你的服务器IP REMOTE_USER"root" TARGET"/var/www/my-project" # 服务器上的网页目录看懂了吗?CI/CD 并没有魔法,它就是用 YAML 脚本把我们平时在本地敲的命令(npm install、npm run build)组合起来,让远程的 Linux 虚拟机帮你执行一遍。
如果面试官问:“我看你简历上没写 CI/CD,你之前公司是怎么部署的?”
💡 黄金回答模板:
“我们之前的项目规模相对比较精简,为了快速迭代,确实采用的是本地打包后、通过脚本或手动部署的方式,没有搭建完整的 Jenkins 或 GitLab CI 平台。
但是我对 CI/CD 的原理和价值非常了解。它的核心就是‘自动化’和‘卡点控制’。在 CI 阶段,通过配置代码规范检查(Eslint)和自动化测试,防止有问题的代码进入主分支;在 CD 阶段,通过统一的构建机进行打包和 SSH 远程分发,避免了人工操作失误。
我私底下自己用 GitHub Actions(或 GitLab CI) 做过个人项目练手,熟悉
.yml文件的编写。如果公司需要,我可以非常快地接入并上手这套流程。”
核心要点: 承认公司客观情况 -> 讲出 CI/CD 的底层本质(自动化、防错) -> 表明自己私下学过,能随时上手。面试官听了绝对会非常满意!
English: CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). In short, it is an automated workflow that helps developers test, build, and deploy their code automatically every time they make changes.
中文: CI/CD 代表持续集成和持续交付/部署。简单来说,它是一套自动化的工作流,每当开发者修改代码时,它就会自动帮我们进行测试、打包和部署。
English (CI): CI (Continuous Integration) focuses on code quality. When you push code, the system automatically runs code linting (like ESLint) and unit tests to ensure the new code doesn't break anything.
中文 (CI): CI(持续集成) 关注代码质量。当你推送代码时,系统会自动运行代码检查(如 ESLint)和单元测试,确保新代码没有把原有的功能改坏。
English (CD): CD (Continuous Delivery/Deployment) focuses on automation. Once the code passes all tests, the system automatically builds the project (like creating the dist folder) and deploys it directly to the server.
中文 (CD): CD(持续交付/部署) 关注自动化发布。一旦代码通过了所有测试,系统会自动打包项目(比如生成 dist 文件夹)并直接部署到服务器上。
I mainly used GitHub Actions for CI/CD. I created a YAML file in the .github/workflows folder. Whenever I pushed code or created a pull request, the pipeline would automatically trigger. It runs unit tests, builds the Docker image, and deploys to the testing environment. This made our development much faster and reduced manual errors.
中文: 我主要用 GitHub Actions 来做 CI/CD。我在 .github/workflows 文件夹里建了一个 YAML 文件,每次 push 代码或者提交 PR,流水线就会自动触发。它会自动跑单元测试、构建 Docker 镜像,然后部署到测试环境。这样开发速度快了很多,也减少了手动出错。